MediaLiveへのRTMP push Input時の接続エラーをログから確認してみた

はじめに

清水です。ブロードキャストグレードのライブ動画処理サービスであるAWS Elemental MediaLive、映像入力の方法の1つにRTMP pushが用意されています。IngestでのRTMPはまだまだ使用機会も多く（RTMPの2021年以降の話 ~ Adobe Flash以外の動画配信での使われ方 | DevelopersIO）、私もこのRTMP push inputをよく利用しま す。

ところで、MediaLiveでRTMP pushのInputを利用する場合、1つのEndpointに対して固定のIPアドレスと、あらかじめ指定したApplication nameならびにApplication instanceで接続します。いわゆるRTMPのパスを含めたサーバURLの指定とストリームキーの指定ですね。多くのストリーミングサービスではサーバURL部分は固定、ストリームキーをユニークなものにすることで同じサーバURLに対して映像の打ち上げを実現しています。しかしMediaLiveの場合はサーバURLが（IPアドレスとして）別のものとなります。

ここで、MediaLiveのRTMP push Inputに対し、すでにあるStreaming SoftwareからRTMPで接続し映像を打ち上げている環境で、別のStreaming Softwareから映像を打ち上げた場合にどうなるか、というのが気になりました。ほかStreaming Serverなどを利用した経験則から、おそらく先に接続しているRTMPコネクションが優先され、あとから接続しようとしたRTMPコネクションは失敗するというのは想像できたのですが、MediaLiveのログ出力などからもこの事象をきちんと確認してみたいと思います。

またあわせて、RTMP pushでの映像打ち上げ時のあるあるとして、Application name（サーバURLのパス部分）やApplication instance（ストリームキー）を間違えてしまい配信ができない、ということがあります。MediaLiveでこのようなEndpointの指定ミスをした場合にどのような挙動やログ出力となるかも確認してみました。

検証環境の準備とMediaLiveのログ設定

まずは検証用のMediaLiveの環境を準備しつつ、ログ出力についても設定も行っていきます。

MediaLiveのchannel logsについて

MediaLiveのログ出力、個人的にきちんとまとめたことはなかったなということで、おさらいを兼ねてMediaLive User Guideを確認していきます。

• About channel logs - MediaLive

MediaLiveで監視を行える項目は複数ありますが、ログ出力についてはchannel logsと呼ばれます。このchannel logsはCloudWatch Logsに出力されます。Encoder logsとAs-run logs（実行ログ）の2種類があり、後者は自動で出力されるログですが、前者はログレベルとともに出力を有効にする必要があります。RTMP接続などに関するログは前者のEncoder logsとして出力されるので、確認のためには別途出力ならびにログレベルの設定が必要となります。ログレベルについてはUser Guideの「Working with logs - MediaLive」も参考にしましょう。

Workflow wizardでMediaLive検証環境を準備

channel logsの確認ができたところで、検証用のMediaLiveリソースを作成します。今回もWorkflow wizardを使用してサクッと作成しました。

MediaLive Channelでログ出力の有効化

vvvv Workflow wizardで作成したMediaLive Channelでは、デフォルト状態でchannel loggingは無効DISABLEとなっています。これをログレベルをともに設定しましょう。

作成したWorkflowのMediaLive Channelの項目、「Link to resource」からChannelの詳細画面に遷移します。

右上[Channel Actions]ボタンから[Modify - Edit channel]で進みます。

General settingsを選択、「General channel settings」の項目の一番下の「Channel logging」、Log levelがDISALBEDとなっていますのでここを変更します。今回はログレベルをDEBUGとしました。変更したら[update channel]ボタンで変更を反映させます。

ライブストリーミングをしながら重複してRTMP ingestをしてみる

MediaLiveのworkflow（Channel）をStartさせつつ、Streaming SoftwareからRTMPで映像を打ち上げてライブストリーミングを開始します。このライブストリーミング用の映像は、iPhone XS上のZixi ONAIRから打ち上げました。

ここでStreaming Softwareに指定するEndpointについても確認しておきましょう。Workflowに紐付いているMediaLive Inputの詳細ページに「Link to resource」から進みます。

Endpoints欄のURLがRTMP接続先の情報になりますね。使用するStreaming Softwareによって指定方法はいくつかありますが、「サーバURL」と「ストリームキー」という指定がある場合は前者にrtmp://43.XXX.XXX.149:1935/app/を、後者にinstを指定します。（なおZixi ONAIRの場合は、「URL」と「Stream Name」というぐあいでした。ここらへんの用語にはけっこうバラつきがありますね。）

ライブストリーミングが正常に視聴できることを確認しつつ、ここでMediaLiveのChannel logsについても確認してみましょう。

CloudWatchのマネジメントコンソール、Logs > Log groupsでElementalMediaLiveというLog groupを探します。ここにMediaLiveのChannel logsは集約されるようです。

Log streamsの名称は以下の2種類があります。

• arn_aws_medialive_[regino]_[account ID]_channel_[Channel ID]_[Pipline #]
• arn_aws_medialive_[region]_[account ID]_channel_[Channel ID]_[Pipline #]_as_run

Pipelineの番号はSingle Pipelineであれば常に0、Standardであれば0もしくは1の2種となります。詳細はUser Guideの「Working with logs - MediaLive」を参照ください。

また末尾に_as_runが付くLog StreamはAs-run logsですので、こちらがついていないほう（Encoder logsになります）を確認します。

この中から、RTMPで映像を打ち上げたタイミングで出力されたログを確認してみましょう。以下のようにRTMP接続が成功しているログが確認できます。なおIPアドレスは接続元の（iPhone XSが接続している）ネットワークのものでした。

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Accepted RTMP connection from 202.XXX.XXX.135:59107 to port 1935",
    "severity": "I",
    "timestamp": "2023-02-28T10:03:12.661840"
}

別のStreaming SoftwareからRTMP ingestしてみる

続いてこのライブストリーミング、RTMP ingestをしながら、別のStreaming Softwareから同じRTMP push Endpointに対してingestをしてみます。iPhone 13 Pro上のZixi ONAIRを使用しました。

Zixi ONAIR上で映像の打ち上げを開始するも、なかなか開始状態に遷移しません。しばらくすると以下のようにConnection Errorと表示されてしまいました。

ライブストリーミングとしても、iPhone XSの映像が流れ続けています。予想していたとおり、先に接続されているRTMP ingestが優先されるという挙動になりました。

MediaLiveのChannel logsについても確認してみましょう。2つ目のStreaming SoftwareからRTMP ingestしたタイミングで以下のログが出力されていました。1つ目のログエントリでRTMPの接続を試みようとしたことがわかります。Streaming SoftwareからMediaLive Endpointまでの疎通はできているということですね。続く2つ目のログエントリは、このRTMP ingestが失敗した具体的な理由、すでに別のRTMP接続が使用されていることが確認できます。

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Accepted RTMP connection from 110.XXX.XXX.68:57836 to port 1935",
    "severity": "I",
    "timestamp": "2023-02-28T10:17:31.046333"
}

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Connection 110.XXX.XXX.68:57836 [AppName:app, AppInstance:inst] to set name inst for stream id 1 but it's already in use by 202.XXX.XXX.135:59107 [AppName:app, AppInstance:inst]",
    "severity": "E",
    "timestamp": "2023-02-28T10:17:31.509223"
}

2つ目のStreaming SoftwareをmacOS上のOBS Studioに変えて確認してみましょう。設定画面に以下の通り、MediaLiveのEndpointを指定します。

[配信開始]ボタンでRTMP ingestを開始しますが、[接続中…]のまま開始される気配はありません。

しばらくすると「ストリームキーにアクセスできない」ということでエラーとなってしまいました。

Zixi ONAIR on iPhone 13 Proのときと同様に、MediaLiveでのライブストリーミング自体は、1台目のStreaming SoftwareであるZixi ONAIR on iPhone XSの映像のままとなっています。

MediaLiveのChannel logsも確認してみましょう。こちらもZixi ONAIR on iPhone 13 Proのときと同様の内容ですね。RTMPのコネクション自体はMediaLive Endpointに届いていることは確認できますが、RTMP ingestは失敗していることがその理由とともに出力されています。

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Accepted RTMP connection from 104.XXX.XXX.192:16670 to port 1935",
    "severity": "I",
    "timestamp": "2023-02-28T10:24:44.147744"
}

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Connection 104.XXX.XXX.192:16670 [AppName:app, AppInstance:inst] to set name inst for stream id 1 but it's already in use by 202.XXX.XXX.135:59107 [AppName:app, AppInstance:inst]",
    "severity": "E",
    "timestamp": "2023-02-28T10:24:44.437367"
}

Application nameやApplication instanceを間違えてしまったケースについても確認してみる

続いてStreaming Software側で指定するApplication name（サーバURLのパス部分）やApplication instance（ストリームキー）を間違えてしまったケースについても確認してみましょう。

Application instanceを間違えてしまったパターン

まずはApplication instance、いわゆるストリームキーを間違えてしまったパターンについてです。本来instと指定するのが正しいところを、stream-keyと指定してしまったとします。Streaming SoftwareはZixi ONAIR on iPhone XSで確認を行いました。

Zixi ONAIRから映像を打ち上げます、Streaming Software上では特にエラーなどは現れません。

しかしライブストリーミングは視聴できない状況でした。MediaLiveのChannel logsには以下のログが記録されていました。RTMPの接続としてはできているが、instanceがマッチしないため映像の処理がおこなわれていない、というような状況になるかと思います。

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Accepted RTMP connection from 202.XXX.XXX.135:59499 to port 1935",
    "severity": "I",
    "timestamp": "2023-02-28T13:22:22.830791"
}

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "An RTMP connection was established with application instance stream-key. This instance doesn't match the instance inst specified in a currently active input.",
    "severity": "W",
    "timestamp": "2023-02-28T13:22:22.963167"
}

Application nameを間違えてしまったパターン

続いてApplication name、サーバURLのパス部分を間違えてしまったパターンです。こちらもZixi ONAIR on iPhone XSから映像を打ち上げます。URLのパス部分、本来/app/とすべきところを/path/としてみます。

映像を打ち上げてみます。先ほどのストリームキーを間違えたときと同様、Streaming Software上では特にエラーなどは発生しません。またライブストリーミングを確認してみると、問題なく視聴ができているではありませんか！（ちょっと意外でした。）

MediaLiveのChannel logsも確認してみましょう。以下のRTMP接続成功のログがあるだけで、特にエラーとなるような情報はありませんでした。

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Accepted RTMP connection from 202.XXX.XXX.135:59512 to port 1935",
    "severity": "I",
    "timestamp": "2023-02-28T13:34:56.547714"
}

さて、この状態から別のStreaming Softwareを用いて重複したRTMP ingestを行ってみます。2つ目のRTMP ingestはZixi ONAIR on iPhone 13 Proを用いました。Application nameとApplication instanceはともに正しいものです。

2つ目のStreaming Softwareから映像を打ち上げると、先ほどと同じようにStreaming Software側では開始状態に遷移せず、しばらくしてConnection Errorとなりました。Channel logでも以下のようにRTMPでの疎通はできていても、別のRTMP接続がすでに使用されているためエラーとなったことがわかります。（正しいAppNameでの接続ができず、間違えたAppNameが優先されるのが少し不条理ではありますが。）

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Accepted RTMP connection from 110.XXX.XXX.68:53890 to port 1935",
    "severity": "I",
    "timestamp": "2023-02-28T13:42:13.841021"
}

{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:478XXXX",
    "encoder_pipeline": 0,
    "logger_name": "rtmp",
    "message": "Connection 110.XXX.XXX.68:53890 [AppName:app, AppInstance:inst] to set name inst for stream id 1 but it's already in use by 202.XXX.XXX.135:59512 [AppName:path, AppInstance:inst]",
    "severity": "E",
    "timestamp": "2023-02-28T13:42:14.593207"
}

個人的には、Application name（サーバURLのパス部分）とApplication instance（ストリームキー）、どちらも間違えてしまうと映像の打ち上げが失敗すると思っていたので、Application nameを間違えても映像が問題なく打ち上がりライブストリーミングができることが意外で驚きでした。また確認してみたところこの挙動はOBS Studioを用いた場合でも同様となりました。Streaming SoftwareにかかわらずApplication nameはMediaLive側でチェックせず、間違えても映像の打ち上げに支障はないのかもしれません。ただし、この点についてMediaLive User Guideなどドキュメントに記載がなく、突然動作が変わる可能性があることも否めません。Application nameもMediaLiveとStreaming Software双方で一致させておくのが原則かと思います。

まとめ

AWS Elemental MediaLiveでログ出力（channel logs）を有効にして、RTMP push Input使用時の接続エラーをログ出力とともに確認してみました。すでにStreaming SoftwareからRTMP接続を行い映像を打ち上げている状況下で、別のStreaming Softwareから映像を打ち上げようとしても先に接続されているRTMP ingestが優先されます。またその際にはその旨、channel logsにも出力があります。そしてストリームキー（Application instance）を間違えて映像を打ち上げてしまった場合はRTMP接続はできますが映像の処理が行われません。ログにもinstanceが合致していないことが出力されますので確認を行いましょう。URLのパス部分（Application name）については間違えてしまっても映像の打ち上げ、ライブストリーミングが可能です念のため一致していることを確認するようにしましょう。

今回改めてMediaLiveのログ出力を確認してみましたが、RTMP接続に関する情報だけでなくほかにも色々と記録されていますね。今回の接続エラーのようにトラブル時の原因究明に役立つのはもちろんですが、MediaLiveがどんな動きをしているか、というのも垣間見える重要な情報源かと思いました。